As remote access of computer systems and applications grows in popularity the number and variety of transactions which are accessed remotely over public networks such as the Internet has increased dramatically. This popularity has underlined a need for security in particular;                a. How to insure that people who are remotely accessing an application are who they claim they are and how to insure the transactions being conducted remotely are initiated by legitimate individuals. This subject is referred to as authentication.        b. How to insure that transaction data has not been altered before being received at an application server. This is referred to as data integrity.        c. How to guarantee that an individual, once having engaged in a transaction, is not in a position to repudiate it. This is referred to as non-repudiation.        
In the past, application providers have relied on static passwords to provide the security for remote applications. In the last couple of years it has become evident that static passwords are not sufficient and that more advanced security technology is required.
PKI Smart Cards
One way of solving the security problems associated with remote access to computer systems and applications over public networks is provided by a Public Key Infrastructure. In a Public Key Infrastructure one associates a public-private key pair with each user. The key pair is associated with a certificate (issued by a trusted Certificate Authority) that binds that public-private key pair to a specific user. By means of asymmetric cryptography this public-private key pair can be used to:                a. authenticate the user,        b. sign transactions, documents, e-mails (so as to prevent repudiation), and        c. set up encrypted communication channels.        
To guarantee an adequate level of security it is mandatory that each user's private key remains secret and can only be accessed (e.g. to create a signature) by the legitimate user associated with that key. It is common to rely on a smart card to store the public-private key pair and the certificate and to carry out the cryptographic calculations involving the private key. The use of the private key by the card is then often PIN-protected.
PKI-enabled smart cards are, and have been issued by:                a. Corporations to their employees or customers to secure the log-in to their computer networks or the remote access to their applications,        b. Banks to their customers to secure e.g. Internet banking applications, and        c. Governments to their citizens as electronic ID cards to create legally binding electronic signatures.        
Apart from the advantages, there are also some disadvantages associated with PKI and the smart cards carrying the PKI keys and certificates:                a. Building a Public Key Infrastructure is generally quite complicated and therefore expensive when compared to competing security technologies.        b. PKI is inherently limited to environments and applications where there is a digital connection between clients and servers. In other words it is unsuitable for telephone banking or other delivery channels where it is not possible to provide a digital connection between the container of the PKI certificate and private key on the one hand and an application server on the other hand.        c. PKI smart cards do not have a power supply or a user interface. PKI smart cards therefore rely on the presence of an interfacing device that provides electrical power to the card, that is capable of digitally exchanging data with the card, and that is capable of interfacing with the user (e.g. capturing the card's PIN and presenting the data that should be signed). In most cases a PC with a connected transparent smart card reader is used. This reduces the mobility of the user (many PCs are not equipped with smart card readers). It also presents a security problem: all user interaction (such as approving a signature or capturing the card's PIN) is done on the inherently insecure PC.Strong Authentication Tokens        
An alternative technology for authentication and transaction signature capabilities is offered by what are called ‘strong authentication token devices’. A typical example of strong authentication token is any one of the Digipass tokens offered by Vasco Data Security Inc., see the website Vasco.com.
A strong authentication token is a small autonomous battery-powered device with its own display and keyboard. In some cases the keyboard is reduced to a single button or even completely omitted. The main purpose of a strong authentication token is to generate so-called ‘One-Time Passwords’ (OTPs). In some cases strong authentication tokens are also capable of generating electronic signatures or Message Authentication Codes (MACs) on data that has been entered on the token's keyboard. If the token has a keyboard, the usage of the token is often protected by a PIN.
To be able to generate OTPs or MACs, strong authentication tokens are capable of doing cryptographic calculations based on symmetric cryptographic algorithms parameterized with a secret value or key. Typical examples of such symmetric cryptographic algorithms parameterized with a secret value or key are symmetric encryption/decryption algorithms (such as 3DES or AES) and/or keyed one-way hash functions (such as MD5 or SHA-1 in OATH compliant tokens). In the remainder of the text the output of such algorithms will sometimes be referred to as ‘symmetric cryptogram’. The terminology ‘symmetric cryptogram’ shall thus be understood as not only the output of a symmetric encryption algorithm but also of symmetric decryption algorithms or keyed hash functions. Strong authentication tokens are personalized with one or more secret keys that are supposed to be different for each individual token. To generate a one-time password or signature, the token typically performs the following steps (refer to FIG. 1):                a. Step 10: The token takes one or more input values (these could include a challenge generated by a server and typed-in on the keyboard by the user, and/or the value of the token's internal real-time clock, and/or the value of an internal counter managed by the token, and/or transaction data typed-in on the token's keyboard by the user).        b. Step 11: The token puts the one or more input values into a specified format.        c. Step 12: The token then cryptographically combines the one or more input values with a personalized secret key 15 stored securely in the token. In a typical strong authentication token the token submits the one or more input values to a symmetric encryption/decryption algorithm and/or one-way hash function parameterized by a personalized secret key 15 stored securely in the token. The result is a cryptogram or a hash value.        d. Step 13: The token transforms the cryptogram or hash value that is the outcome of this encryption/decryption or one-way hash (or more generally, some other cryptographic combination) into the actual OTP or MAC. i.e., the cryptogram or hash is typically truncated, converted in a human readable format (e.g. through decimalization) and visualized on the display. The user may submit this value to the application server.        
In the remainder of the text one-time passwords or electronic signatures generated by strong authentication tokens as described above may be referred to as dynamic authentication credentials or just dynamic credentials. In the remainder of the text the input values referred to in step 10 may be referred to as dynamic variables. Dynamic variables the value of which comes from a source that is external to the strong authentication token may be referred to as external dynamic variables. Examples of external dynamic variables may include a challenge or transaction data that e.g. may be provided to the token by a user entering them on the token's keyboard. Dynamic variables the value of which comes from a source that is internal to the strong authentication token may be referred to as internal dynamic variables. Examples of internal dynamic variables may include a time-value that is provided by a token's real-time clock or a counter that is stored in a token's memory and updated by the token's processor. The algorithms published by the “OATH—initiative for open authentication” are an example of standardized algorithms for generating dynamic credentials.
In most cases a strong authentication token is a physical device, however in some cases the functionality of these strong authentication tokens to generate OTPs or MAC signatures is emulated by software running on a PC, a workstation, a mobile phone, a personal organizer, a PDA, etc. The latter are referred to as “soft tokens”.
Once the OTP or MAC has been produced it is conveyed to an entity where the value can be verified as authenticating the user or the message, see FIG. 2. Typically the entity is an application server. The application server stores data for each token, including which secret key(s) the token has been personalized with, and the identity of the user associated with the token. To validate a one-time password or signature, the server retrieves the secret key (115) which is a copy of the key personalized in the token, takes the same inputs that were used by the token and in essence performs the same algorithm 112 as the token. The server then compares 120 the result it obtained with the value it received. (In practice, the validation of an OTP or MAC is often somewhat more convoluted if the strong authentication algorithm is time-based or counter-based, due to synchronization issues.) Since a one-time password or signature generated by a strong authentication token is a function of the token's individual secret key and the always different values of the input(s) to the token algorithm, validating the correctness of the one-time password or signature gives the application server a very high degree of confidence that the person submitting the one-time password or signature possesses the correct token and knows its PIN (if the token is PIN protected), which in turn gives a high degree of confidence that that person is indeed the legitimate user associated with that token device.
Because the OTP verification server and the OTP token in essence perform the same algorithm with the same key, the OTP generation algorithm can be a one-way or non-reversible function. That means that the actual OTP can be shorter than the cryptogram or hash value from which it is derived. This allows for OTP or MAC lengths that are sufficiently short so that it is not too inconvenient for users to manually copy the OTP or MAC values from the token display onto a PC. As a consequence strong authentication tokens don't require a digital connection between the token and the verification server.
The major advantages of strong authentication tokens when compared to PKI cards are:                a. They are fully autonomous (tokens have their own power supply and their own user interface);        b. They are independent of the delivery channel or communication medium (tokens don't require any digital or electronic connection with any other device; all input and output of data is done by the user via the token's display and keyboard); and        c. They offer a very high level of security (all user interaction such as capturing the PIN or providing transaction data to be signed is done via the token's own secure user interface).        
In some cases where smart cards have been issued, one wants to get around the disadvantages and limitations associated with smart cards and achieve the same advantages that strong authentication tokens offer i.e. full autonomy, independence of the delivery channel, and a secure user interface.
One alternative is to combine the smart card with an unconnected, battery-powered smart card reader that has its own display and keyboard. The idea is that the combination of the smart card and the unconnected smart card reader emulates a strong authentication token. The functionality normally provided by a strong authentication token is then split over the smart card and the unconnected reader. The unconnected reader takes care of all user interface, and all or a part of the other token functionality is delegated to the card.
Typically, all personalized secrets and security sensitive data are stored and managed by the card (e.g. the PIN is stored and verified by the card, the secret keys are stored on the card and all cryptographic operations involving those keys are done by the card, counters used as input for the token algorithm are stored and managed by the card). Part of the token functionality that is less sensitive (e.g. truncating and converting the generated hashes or cryptograms) often happens in the reader. An example of this combination is discussed below.
This principle is often used by banks that combine the bank cards they issue (for usage at Automatic Teller Machines or Point Of Sale terminals) with unconnected readers to secure their remote banking applications (such as internet banking or telephone banking). A good example of this is the Mastercard Chip Authentication Programme (CAP), which specifies how EMV smart cards can be used in combination with unconnected smart card readers to generate one-time passwords and electronic transaction data signatures.
This technology relies on the smart cards being capable of doing symmetric cryptographic operations and having been personalized with a secret key to be used for symmetric cryptographic operations. However, PKI-enabled smart cards are designed to store asymmetric keys and do asymmetric cryptographic operations. Many PKI-enabled smart cards don't support symmetric cryptographic operations or (if they do) have never been personalized with an individual symmetric secret key.
Traditional PKI Signatures
The usual way to create an electronic signature with a PKI smart card, is that the input data (usually, the input data consist of a hash of the actual transaction data one wants to sign) are encrypted by the card's private key.
The usual way to validate such a signature, is that the validating entity decrypts the received signature with the public key. If the decryption of the signature results in the same value as the input data that were supposed to have been encrypted by the private key, the signature is validated successfully. Note that thanks to this asymmetric characteristic the validating entity never needs to have access to the card's private key. This allows the private key to be kept secret from any party other than the signing party, even from any verifying party, thus providing for true non-repudiation.
This can only be done successfully if the signature itself is in its entirety available to the validating entity. The decryption of an incomplete signature would only result in meaningless data that can not be compared with the input data that were supposed to have been signed.
This condition can not be fulfilled in practice when small hand-held unconnected smart card readers are being used: given that a typical PKI signature size is in the order of 100 bytes, the display of these readers is far too small to display a full signature and it is in any case totally unrealistic to expect a user to manually transfer a 100-byte value from the reader's display to a PC without making a single mistake. The 100-byte typical PKI signature should be compared to a typical 6 to 8-digit or 3 to 4-byte OTP or MAC of a traditional strong authentication token. This is certainly a reason why asymmetric cryptography and private keys have not been used to generate OTPs and MACs by e.g. strong authentication tokens.
What is desired is a method and apparatus that:                a. allows the usage of a device storing PKI private keys (such as PKI-enabled smart cards or USB sticks) to authenticate users and to sign transactions,        b. without the need for any user application to have some kind of a direct or indirect digital connection with the device containing the private key, in particular a digital connection that would allow the user application to submit data to the card for signing by the card's private key and that would allow retrieval of the entire resulting signature from the card should not be necessary,        c. without the need for the PKI-enabled device containing the private key (e.g. a PKI smart card or USB stick) to:                    1. either support symmetric cryptographic operations, or            2. to have been personalized with some secret or confidential data element that can be read by a suitable reader.                        